home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19961006-19970104 / 000262_news@columbia.edu _Thu Dec 5 02:58:50 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  7KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.8.3/8.8.3) with ESMTP id CAA18933 for <kermit.misc@watsun.cc.columbia.edu>; Thu, 5 Dec 1996 02:58:43 -0500 (EST)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.8.3/8.8.3) id CAA08880 for kermit.misc@watsun; Thu, 5 Dec 1996 02:58:41 -0500 (EST)
  4. Path: news.columbia.edu!psinntp!psinntp!howland.erols.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  5. From: jrd@cc.usu.edu (Joe Doupnik)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: Random login prompt with K95
  8. Message-ID: <1996Dec4.205928.90168@cc.usu.edu>
  9. Date: 4 Dec 96 20:59:27 MDT
  10. References: <1996Dec3.161932.1217@cesi> <581mdn$3lf$1@apakabar.cc.columbia.edu> <5824av$f1v$1@apakabar.cc.columbia.edu>
  11. Organization: Utah State University
  12. Lines: 119
  13.  
  14. In article <5824av$f1v$1@apakabar.cc.columbia.edu>, fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
  15. > In article <581mdn$3lf$1@apakabar.cc.columbia.edu>,
  16. > Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:
  17. > : In article <1996Dec3.161932.1217@cesi>,
  18. > : Alberto Meregalli (DIF) <meregalli@cesi.it> wrote:
  19. > : : ...
  20. > : : What the user sees is that the "Username:" prompt doesn't appear
  21. > : : regularly, but rather randomly. What seems to be apparent in the
  22. > : : sniffer captures is that while many option negotiations go on the VAX
  23. > : : always immediately refuses the NEW-ENVIRONMENT option, but all data
  24. > : : sent out by it before K95 acknowledges that with a WON'T
  25. > : : NEW-ENVIRONMENT are not revealed to the user. So if the VAX delays a
  26. > : : little sending out the prompt, that's shown to the user, otherwise it
  27. > : : is lost.
  28. > :
  29. > Followup #2, in which a more likely explanation is offered, based on
  30. > the fact that Kermit 95 1.1.8 is the first version to support "true"
  31. > terminal type negotiation.
  32. > 
  33. > : : - option 31 (Negotiate About Window Size): it is "negotiated" up to
  34. > : : four times: that is K95 sends out up to four times the same 80 columns
  35. > : : x 24 lines dimension
  36. > :
  37. > This is probably happening because the terminal type is being renegotiated:
  38. > "My terminal type is VT320", "I don't like that one, please try another",
  39. > "OK, it's VT220", etc etc.  This is documented in section 6.2 of UPDATES.DOC.
  40. > 
  41. > It could be the root of all the other symptoms you have reported.
  42. > In a test on a nearby VMS system, K95's debug log includes the following:
  43. > 
  44. > TELNET SENT WILL TERMINAL-TYPE
  45. > TELNET SENT WILL NEGOTIATE-ABOUT-WINDOW-SIZE
  46. > TELNET RCVD DO TERMINAL-TYPE
  47. > TELNET RCVD DO NEGOTIATE-ABOUT-WINDOW-SIZE
  48. > TELNET SENT SB NAWS 80 49 IAC SE
  49. > TELNET RCVD SB TERMINAL-TYPE SEND  IAC SE
  50. > TELNET SENT SB TERMINAL-TYPE IS VT320 IAC SE  <-- We tell our terminal type
  51. > 
  52. > Welcome to Blah Blah VMS V6.2      <-- VMS host sends herald and prompt
  53. > Username:
  54. > 
  55. > So far so good.  But VMS doesn't like the VT320 terminal type, so it sends
  56. > a message asking us to try another one, so we drop down to VT220:
  57. > 
  58. > TELNET RCVD SB TERMINAL-TYPE SEND  IAC SE
  59. > TELNET SENT SB NAWS 80 49 IAC SE
  60. > TELNET SENT SB TERMINAL-TYPE IS VT220 IAC SE
  61. > 
  62. > But whenever we change terminal types we have to clear the screen.  Why?
  63. > Because different terminal types might have different dimensions, coloration,
  64. > attributes, etc, and we must initialize all of this when switching emulations.
  65. > So now the user sees a blank screen.  (Scrollback would reveal the herald
  66. > and Username: prompt on the previous screen.)  And we also have to
  67. > renogiatiate all the other stuff (screen size via NAWS, etc).
  68. > 
  69. > The problem is that VMS (Multinet) is trying to do all this AFTER the 
  70. > herald and Username prompt have been issued, rather than before, and that's
  71. > why the Username prompt disappears.  In this case, it would have nothing
  72. > at all to do with the NEW-ENVIRONMENT (username) negotiation.
  73. > 
  74. > The workaround would be to fix VMS to accept VT320 as a terminal type
  75. > (why doesn't it?), or set Kermit's emulation to VT100 or whatever it is
  76. > that VMS is expecting.
  77. > 
  78. > - Frank
  79. -----------
  80.     The thread is also running on the Multinet listserver. The suggestion
  81. from TGV/Cisco is use string  vt300_series   as the terminal ident. Tried here
  82. all in lower case and it did stick on the first query. Meanwhile TGV says
  83. they will think about all of this.
  84.     While it is convenient to complain to TGV we should also keep in
  85. mind that VMS itself classes terminals by major number (100, 200, etc, or in
  86. VMS-speak DEC_CRT, DEC_CRT2, etc) and then depends on a detailed report of 
  87. capabilities to handle operations. This means a VT320 isn't known to VMS as
  88. a VT320, but as a VT300_Series with certain features (variable from model to 
  89. model of VT320 too). MS-DOS Kermit and Kermit95 know how to report these 
  90. features and thus VMS itself is most happy with them. Below is what MSK v3.15
  91. beta looks like to VMS v6.1 (via Multinet 4.0A):
  92.  
  93. $ sh term
  94. Terminal: _NTY26:     Device_Type: VT300_Series  Owner: JRD
  95. Remote Port Info: jrd.usu.edu
  96.  
  97.    Input:    9600     LFfill:  0      Width:  80      Parity: None
  98.    Output:   9600     CRfill:  0      Page:   24
  99.  
  100. Terminal Characteristics:
  101.    Interactive        Echo               Type_ahead         No Escape
  102.    Hostsync           TTsync             Lowercase          Tab
  103.    Wrap               Scope              Remote             Eightbit
  104.    No Broadcast       No Readsync        No Form            Fulldup
  105.    No Modem           No Local_echo      Autobaud           Hangup
  106.    No Brdcstmbx       No DMA             No Altypeahd       Set_speed
  107.    No Commsync        Line Editing       Insert editing     No Fallback
  108.    No Dialup          No Secure server   No Disconnect      No Pasthru
  109.    No Syspassword     SIXEL Graphics     No Soft Characters Printer port
  110.    Numeric Keypad     ANSI_CRT           No Regis           No Block_mode
  111.    Advanced_video     Edit_mode          DEC_CRT            DEC_CRT2
  112.    DEC_CRT3           No DEC_CRT4        No DEC_CRT5        Ansi_Color
  113.    VMS Style Input
  114. $
  115.  
  116.     Note the "Ansi_Color" which a real VT320 lacks, and "No Soft
  117. Characters" which a real VT320 posseses. Quite a complicated set of
  118. ingredients. But Telnet daemons ought to be a triffle smarter than this in 
  119. accepting well known terminal identifications such as "VT320" (case 
  120. insensitive please). Even VT3xx or VT2xx would be a good first step in
  121. recognizing terminal kinds, where xx are any digits. To ensure MSK's 
  122. capabilities are understood by VMS, despite Telnet Options, I add 
  123. SET TERM/INQUIRE to the login process to request a detailed report from 
  124. the terminal.
  125.     We see something else in Frank's material above. Telnet Options
  126. don't have a way of saying, "What's a VT320? I can't deal with that. What
  127. else can you pretend to be?" and thereby indicate to the terminal emulator
  128. to change characteristics. Instead the terminal type option query is simply
  129. repeated, and repeated, to elicit a shopping list. That is not a good 
  130. negotiation design (pumping dry the victim), and it ratchets one way. 
  131. But "it's too late now."
  132.     Joe D.